Merging this PR will not alter performance

✅ 9 untouched benchmarks

_{Comparing FarhanAliRaza:flaky-test (497de71) with main (8f7ad9a)}

Greptile Summary

This PR fixes a flaky test by replacing asyncio.sleep with a DOM-polling helper (expect_upload_in_flight) that waits until the upload is verifiably in-flight (0 < progress < 1) before clicking cancel, tying cancel timing to actual upload state rather than wall-clock time. The final assertions are also tightened to only examine progress entries created during the current test run via an initial_progress_count slice.

Confidence Score: 4/5

Safe to merge; test-only change with a well-designed fix for a known flaky pattern.

Only one P2 style observation about diagnostics on timeout; the core logic is sound and the approach directly addresses the documented race condition.

No files require special attention beyond the one P2 note on expect_upload_in_flight.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Test as Test (pytest)
    participant Browser as Browser / WebDriver
    participant DOM as DOM (progress_dicts)
    participant Server as Upload Server

    Test->>Browser: send_keys(target_file)
    Test->>Browser: upload_button.click()
    Browser->>Server: Start throttled upload (1 Mbps)
    loop poll every 250ms (≤15s)
        Test->>DOM: find_elements(progress_xpath)[initial_count:]
        DOM-->>Test: progress entries
        Test->>Test: any 0 < progress < 1?
    end
    Note over Test: in-flight confirmed
    Test->>Browser: cancel_button.click()
    Browser->>Server: abort()
    Test->>Test: asyncio.sleep(12) — upload would finish if cancel failed
    Test->>DOM: find_elements(progress_xpath)[initial_count:]
    DOM-->>Test: progress entries
    Test->>Test: assert no progress == 1
    Test->>Server: assert file not written

_{Reviews (1): Last reviewed commit: "test: cancel upload by observing progres..." | Re-trigger Greptile}

supersede by #6424 with various improvements